UNIVERSITATEA POLITEHNICA BUCURESTI METRICI ALE COMPLEXITATII SOFTWARE Iliuta Virgil Balint George GRUPA 441A Metrici software Metricile software sunt modele(reguli) folosite pentru a masura cantitativ anumite caracteristici ale sistemelor informatice Metricile software înglobeazã modele, indicatori si proprietãtile acestora, precum si modalitãti de evaluare si validare Metricile software se folosesc pentru a reduce subiectivitatea aprecierii unui program Definitie matematica: Metrica software este un model matematic dezvoltat în jurul unei ecuatii de forma: y = f( x ) Un model matematic cuprinde una sau mai multe ecuatii, inecuatii si are una sau mai multe functii obiectiv, iar rolul lui este de a descriestarea sistemuluiasociat Metrica software are rolul de a masura o anumita caracteristica a unui produs program, luând în calcul factorii ce influenteaza nivelul caracteristicii masurate Aplicându-se tuturor produselor software dintr-un lot omogen, metrica devine instrumentul prin intermediul caruia se efectueaza clasificari si ierarhizariale produselor software O metrica software este functie obiectiv a modelului matematic caruia îi apartine, daca prin aplicarea ei se are în vedere maximizarea sau minimizarea nivelului caracteristicii cercetate în functie de toti factorii deinfluenta: f(X) ß unde: X - vectorul factorilor ce influenteaza caracteristica software masurata; a si ß- niveluri limita admise Metrica software este restrictie a modelului matematic daca plaseaza nivelul masurat al caracteristicii într-un interval definit de: ß Utilizeaza Graful de Control al programului Ipoteza: dificultatea de intelegere a unui program este in mare masura determinata de complexitatea grafului fluxului de control > Este o masura a dificultatii de testare a modulelor si a fiabilitatii la nivel de modul Complexitatea unei entitati este determinata de relatiile dintre partile sale Partile unui modul software sunt instructiunile sale Relatiile dintre ele se bazeaza pe trei structuri: * Secventa: bloc maximal indivizibil de instructiuni care se executa intotdeauna in aceeasi ordine * Selectia (conditia) * Iteratia (ciclul) Iteratia poate fi simulata prin salt la o conditie Complexitatea ciclomatica este definita pentru un modul pe baza grafului de control al modulului McCabe defineste complexitatea ciclomatica a unui graf de control astfel: v = e - n + 2 unde: ??e este numarul de arce (edges); ??n este numarul de noduri > Pentru o secventa, v=1 Este necesara o singura executie de test pentru a executa fiecare instructiune din secventa > Fiecare salt adaugat la un modul creste complexitatea sa cu 1 si necesita o executie de test suplimentara pentru testarea sa Deci, complexiatea ciclomatica a unui modul da numarul minim de executii de test ale unui modul, pentru acoperirea tuturor arcelor Grafuri de control Grafuri de control pentru structurile de control ale "Programarii structurate" Instructiunile de decizie cu mai multe predicate trebuie sa fie separate in predicate simple inainte de masurarea complexitatii ciclomatice De exemplu, decizia if(A and B andC)then trebuie separata in 3 decizii simple > Metoda de testare structurala: complexitatea ciclomatica a unui modul sa fie limitata la 10 Studiile arata ca erorile se concentreaza in module cu complexitati mai mari ca aceasta limita > In timpul proiectarii de detaliu limitarea trebuie sa fie la 7, deoarece complexitatea creste intotdeauna in timpul codarii Modulele care depasesc aceasta limita trebuie sa fie reproiectate 2 Complexitatea ciclomatica totala Complexitatea ciclomatica totala a unui program se obtine insumand complexitatile ciclomatice ale modulelor sale Este exprimata prin formula: v = e - n + 2p unde p este numarul de module e este numarul de arce din toate modulele n este numarul de noduri din toate modulele O formula echivalenta este: v = v1+v2+ +vp unde v1, v2, , vp sunt complexitatile ciclomatice ale celor p module > Combinand mai multe module intr-unul singur va rezulta un modul cu o complexitate ciclomatica mai mare decat a modulelor combinate dar mai mica decat complexitatea totala > Descompunerea unui modul in module mai mici creste complexitatea totala dar reduce complexitatea la nivelul fiecarui modul 3 Complexitatea proiectarii modulelor Complexitatea proiectarii unui modul, notata de McCabe cu iv, masoara efectul individual al unui modul asupra proiectului programului Complexitatea proiectarii unui modul este evaluata plecand de la graful de control al modulului si marcand nodurile care contin apeluri de module externe Graful de control este apoi redus dupa urmatoarele reguli: 1 nodurile marcate nu pot fi eliminate; 2 nodurile nemarcate care nu contin decizii sunt eliminate; 3 arcele care intorc controlul la inceputul unui ciclu care contine numai noduri nemarcate sunt eliminate 4 arcele care unesc nodul de start al unei instructiuni case cu nodul de sfarsit sunt eliminate daca nici una dintre celelalte ramificatii ale instructiunii case nu contin noduri marcate Exemplu: > Complexitatea proiectarii modulului este complexitatea ciclomatica a grafului redus (iv = e-n+2) > Complexitatea proiectarii modulului ignora caile acoperite in testarea modulului, care nu contin apeluri de module externe Caile ramase sunt necesare pentru a testa interfetele modulului 4 Complexitatea proiectarii unui ansamblu de module S0 = iv1 + iv2 + ivn unde iv1, iv2, ivn sunt complexitatile de proiectare ale modulelor din ansamblu 5 Complexitatea integrarii Complexitatea integrarii unui ansamblu de N module, notata de McCabe cu S1, Este definita astfel: S1 = S 0 - N + 1 > Complexitatea integrarii a N module care nu contin ramificatii este deci 1 > Formal, complexitatea integrarii necesita masurarea complexitatii proiectarii fiecarui modul > In timpul proiectarii arhitecturale, de regula, nu este disponibil graful fluxului de control al fiecarui modul Totusi, ar trebui sa fie disponibila suficienta informatie pentru a defini complexitatea proiectarii fiecarui modul, chiar fara a cunoaste logica modulelor Figura urmatoare reda o diagrama de structura prin care se ilustreaza cum trebuie evaluata S1 cunoscand doar conditiile de apel ale fiecarei componente, adica fluxul controlului Dreptunghiurile corespund componentelor de proiectare iar sagetile marcheaza fluxul controlului Prin romb se indica un transfer al controlului conditional: ??componenta a apeleaza fie componenta b fie componenta c ??componenta b apeleaza secvential componenta d si componenta e ??componenta c apeleaza una dintre componentele e, f, g sau nici una Complexitatea integrarii modulelor reprezentate in diagrama de structura este 5 Estimarea complexitatii integrarii folosind diagrama de structura 6 Alte metrici ale proiectarii Numarul de parametri * Determina puterea cuplarii intre module * Intelegerea modulelor cu un numar mare de parametri cere mai mult timp si efort * Modificarea modulelor cu un numar mare de parametri poate avea efecte asupra altor module Numarul de module apelate estimeaza complexitatea intretinerii > Pentru un modul: * Fan-in: numarul de module care il apeleaza * Fan-out: cate module sunt apelate de el "Fan-in" mare: un numar mare de module depind de el "Fan-out" mare: modulul depinde de multe module Cuplarea prin date Fie tripletul (p,X,q), unde: o p si q sunt module o X este o variabila accesibila din p si q * Cuplarea potentiala prin date: o X este declarata in ambele, dar nu se verifica accesul la ea o Reflecta posibilitatea ca p si q sa comunice prin variabila X * Cuplarea prin date utilizate o p si q utilizeaza X o Mai greu de determinat decat cuplarea potentiala Necesita mai multa informatie despre logica interna a modulului * Cuplarea prin date efectiva o p atribuie o valoare lui X si q o refera o Cel mai greu de determinat, dar indica un flux de informatie de la p la q Metrici ale coeziunii * Se construieste graful de flux pentru un modul o Pentru fiecare nod, se inregistreaza variabilele referite in instructiunile din nod * Se determina cat de multe cai independente ale modulului trec prin fiecare nod o Un modul are coeziune mare daca cea mai mare parte a variabilelor sunt utilizate pe majoritatea cailor o Cea mai mare coeziune: toate caile independente utilizeaza toate variabilele din modul COMPLEXITATEA HALSTEAD Metrica Halstead este definita prin indicatorii: C = complexitatea programului E = efortul de programare V = volumul programului L = nivelul programului unde: sau, considerând si putem scrie: având aceeasi semnificatie ca si , dar contorizeaza totalurile, nu numai pe cele distincte V* este volumul minim al programului, care este calculat din numarul minim de parametrii I/O necesar pentru a specifica operatia unui algoritm si returul rezultatului, având expresia: , iar este numarul de parametri de I/O folositi în apelul programului cu: n1 - numarul de tipuri fundamentale de date care apar distinct în program n2 - numarul de tipuri derivate de date care apar distinct în program n3 - numarul de instructiuni distincte utilizate de programator n4 - numarul de operanzi distincti care apar în program n5 - numarul de operatori distincti pentru referire care apar în program n6 - numarul de functii distincte apelate 3 COMPLEXITATEA MCCABE Modelul McCabe este folosit pentru evaluarea complexitatii programelor În ipoteza omogenitatii perfecte a instructiunilor se construiesc grafuri asociate secventelor de program, pentru care se masoara complexitatea, fiecare instructiune I1, I2, In fiind reprezentata de un nod, ordinea de executie a acestora fiind evidentiata cu ajutorul arcelor De exemplu, pentru secventa de program S1: 1 2 3 Fig 1 Graful asociat secventei de program S1 C = m-n+2, unde m este numarul arcelor din graf, iar n este numarul nodurilor grafului În secventa de program S1, complexitatea McCabe are valoarea C=2-3+2=1 Pentru o secventa S2: A=B+1; 4 1 2 3 6 5 Complexitatea McCabe a acestuia are valoarea C=6-6+2=2 Se observa ca valoarea complexitatii McCabe depinde de numarul de structuri alternative si de numarul de cicluri cuprinse în secventa analizata Valoarea complexitatii McCabe este egala cu numarul maxim de drumuri liniare independente din graf Studiile au aratat ca exista o proportionalitate directa între complexitatea McCabe si frecventa erorilor O valoare mai mica de 10 a complexitatii McCabe reflecta structuri de program de complexitate scazuta, usor de înteles si de modificat, riscul de aparitie a erorilor fiind redus, în timp ce valori ale complexitatii McCabe mai mari de 50 caracterizeaza secvente de program greu de înteles, având un risc foarte mare de aparitie a erorilor Complexitatea McCabe este extinsa pentru a permite masurarea complexitatii sistemelor informatice Valoarea complexitatii McCabe este calculata în faze avansate ale procesului de dezvoltare de software, neputând fi un instrument eficient în activitatea de management a proiectelor E folosit ca instrument de predictie a costurilor si eforturilor viitoare consumate în procesul de mentenanta 1 LINII DE COD LOC Produsul software poate fi evaluat în mod direct fie indirect Prin evaluarea directã a procesului de inginerie software se întelege determinarea costurilor si a eforturilor asociate Ea presupune calculul numãrului liniilor de cod (LOC - lines of code) scrise, determinarea vitezei de executie, a dimensiunii memoriei, precum si a numãrului de defecte raportat într-un anumit interval de timp Evaluarea indirectã a produsului reprezintã în fapt o analizã a functionalitãtii, calitãtii, complexitãtii, eficientei, fiabilitãtii, întretinerii si multor altor caracteristici Costul si efortul necesar pentru a dezvolta software, calculul numãrului de linii de cod (LOC) precum si alte estimãri directe sunt relativ usor de estimat initial Totusi, calitatea si functionalitatea sau eficienta si întretinerea sunt mult mai dificil de evaluat si pot fi mãsurate doar în mod indirect Metodele de evaluare ale produsului pot fi descrise dupã cum urmeazã: * Evaluarea productivã se concentreaza asupra rezultatelor finale ale procesului de inginerie software; * Evaluarea calitativã oferã o indicatie a cât de aproape este produsul software de cerintele implicite si explicite ale clientului; * Evaluarea tehnicã evidentiazã mai degraba caracteristicile produsului software (ex : complexitatea logicã, gradul de modularizare) decât procesul prin care acesta a fost dezvoltat; * Evaluarea dimensionalã este utilizatã pentru a "colecta" evaluãrile directe ale rezultatelor si calitãtii procesului de inginerie software; * Evaluarea functionalã oferã o evaluare indirectã; * Evaluarea orientatã pe resursele umane oferã informatii asupra modului în care programatorii dezvoltã un produs software precum si asupra perceptiei eficientei instrumentelor si modelelor de dezvoltare În continuare vom face o abordare detaliatã a douã dintre metodele de evaluare expuse ce sunt mai frecvent utilizate de cãtre casele de soft 1 Metoda evaluãrii dimensionale Evaluarea dimensionalã a produsului software reprezintã o estimare directã a acestuia precum si a procesului prin care el este dezvoltat Daca un manager de proiect mentine înregistrãri simple, poate fi creat un tabel cu datele ordonate dupa criteriul dimensiunii Pentru fiecare proiect, datele dimensionale uzuale sunt: * efortul estimeazã necesarul de resurse umane si se mãsoarã în programatori-pe-lunã sau programatori-pe-an; * KLOC (Kilo Lines of Code) - mii de linii de cod; * valoarea este exprimarea bãnescã a efortului; * pagini de documentatie; * numãrul de erori raportate de utilizatori într-o perioadã de timp (de pildã un an) * numãrul de programatori care au lucrat la dezvoltarea produsului software Din datele primare continute într-un astfel de tabel poate fi realizatã o evaluare a productivitãtii si una a calitãtii, orientate dimensional, pentru fiecare proiect în parte: Productivitatea = KLOC / Programatori-pe-lunã Calitatea = Numãr de erori / KLOC În completare, pot fi calculati alti parametrii interesanti: Cost = Valoare / KLOC Documentatie = Pagini de documentatie / KLOC Utilizarea parametrilor dimensionali (KLOC, efort, etc ) este controversatã si ei nu sunt universal acceptati ca reprezentând cea mai bunã metodã de evaluare a procesului de dezvoltare software Controversa se învârte în jurul utilizãrii liniilor de cod LOC ca mãrime principalã Sustinãtorii variabilei LOC afirmã cã aceasta este un artefact al tuturor proiectelor de dezvoltare software si poate fi usor calculatã, cã multe modele de estimare utilizeazã LOC sau KLOC ca date de intrare principale si cã existã deja o literaturã imensã (plus date asociate) dedicatã LOC Pe de alta parte, opozantii reclamã cã variabila LOC este dependentã de limbajul de programare, cã LOC poate penaliza programe bine proiectate dar scurte, cã nu se poate asocia usor limbajelor neprocedurale si cã utilizarea ei în estimare necesitã un nivel de detaliere care poate fi dificil de obtinut (ex: managerul de proiect trebuie sã estimeze numãrul de linii de cod ce trebuie produse cu mult înainte ca analiza si proiectul programului sã fi fost încheiate) 2 Evaluarea Functionalã Parametrii ce caracterizeazã din punct de vedere functional produsul software reprezintã o evaluare indirectã a acestuia si a procesului prin care el este dezvoltat Evitând calculul LOC, parametri functionali se concentreaza asupra "functionabilitãtii" sau "utilitãtii" programului Acest tip de evaluare a fost propus pentru o abordare prin mãsurarea productivitãtii, numitã metoda scorului functional Scorul functional (SF) este obtinut utilizând o relatie empiricã bazatã pe estimãri calculabile ale domeniului de informatie al produsului precum si pe evaluãri ale complexitãtii aplicatiei Valorile domeniului de informatie se definesc în urmãtorul mod: * Numãrul de intrari a utilizatorului: Fiecare intrare a utilizatorului care furnizeazã aplicatiei date distincte orientate cãtre aceasta este luatã în calcul Intrãrile vor trebui distinse de interogãri, care sunt calculate separat * Numãrul de iesiri a utilizatorului: Fiecare iesire cãtre utilizator, care furnizeazã acestuia informatii orientate cãtre aplicatie, este luatã în calcul În acest context termenul "iesire" se referã la rapoarte, ecrane, mesaje de eroare, etc Datele individuale ale unui raport nu sunt calculate separat * Numãrul de interogãri a utilizatorului: O interogare este definitã ca o intrare on-line ce are drept rezultat generarea unui rãspuns imediat al aplicatiei sub forma unei iesiri on-line Fiecare interogare distincta este luatã în calcul * Numãrul de fisiere: Fiecare fisier logic de tip "master", cum ar fi o colectie logicã de date care poate fi parte a unei baze de date largi sau a unui fisier individual, este luat în calcul * Numãrul de interfete externe: Toate interfetele citibile de cãtre masinã (fisiere de date pe bandã sau disc dur) care sunt utilizate pentru a transmite informatii cãtre alt sistem sunt luate în calcul Odatã ce datele de mai sus au fost colectate, un indice de complexitate este asociat fiecãrui calcul Organizatiile care utilizeazã metoda scorului functional dezvoltã criterii pentru a stabili faptul dacã o anumitã intrare este simplã, medie sau complexã Bineinteles, determinarea complexitãtii este un proces relativ subiectiv Pentru a calcula scorul functional, este utilizatã urmãtoarea relatie: SF = totalul-de-calcul * 0 65 + 0 01 * SUM (Fi) unde totalul-de-calcul este suma rezultatelor partiale obtinute prin ponderarea valorilor domeniului de informatie Valorile constante din ecuatia de mai sus precum si factorii de influentã care sunt aplicati calculului domeniului de informatii sunt determinati empiric Valorile de ajustare a complexitãtii (Fi, i=1 14) se determinã evaluând influenta a 14 factori: * Necesitã sistemul back-up si recovery * Sunt necesare facilitãti de comunicatii de date * Sunt necesare functii de procesare distribuitã * Este criteriul performantei critic * Va rula sistemul într-un mediu operational utilizat intens * Necesitã sistemul intrãri de date în regim on-line * Necesitã sistemul de intrãri de date în regim on-line, ca procesul de introducere al datelor sã aibã loc pe ecrane sau prin operatiuni multiple * Sunt fisierele actualizate on-line * Sunt intrãrile, iesirile si interogãrile complexe * Este procesul intern complex * Este codul proiectat astfel încât sã fie reutilizat * Sunt conversia si instalarea programului incluse în design * Este sistemul proiectat pentru instalãri multiple în organizatii diferite * Este aplicatia proiectatã astfel încât sã faciliteze modificarea si usurinta în utilizare din partea beneficiarului Fiecare factor este evaluat cu o notã de la 0 la 5, având semnificatiile: 0 - Nu influenteazã; 1 - Incidental; 2 - Moderat; 3 - Mediu; 4 - Semnificativ; 5 - Esential; Odatã ce scorul functional a fost calculat, el este utilizat într-o manierã asemãnatoare cu metoda LOC ca o mãsurã a productivitãtii, a calitãtii si a altor atribute ce definesc programul: Productivitatea = SF / Programatori-pe-lunã Calitatea = Numãr Defecte / SF Costul =Valoare / SF Documentatia = Pagini de Documentatie / SF Evaluarea pe baza scorului functional a fost conceputã initial pentru a putea fi utilizatã în sistemele de informatii pentru afaceri Totusi, extinderea propusã ulterior, denumitã scor caracteristic (SC), poate permite aplicarea acestei metode si în cazul programelor din domeniul sistemelor ingineresti Scorul caracteristic este adecvat descrierii aplicatiilor în care complexitatea algoritmilor este înaltã Aplicatiile în timp real, de control al proceselor precum si cele orientate spre obiecte au tendinta de a avea o complexitate algoritmicã mare si sunt prin urmare potrivite evaluãrii prin metoda scorului caracteristic Pentru a calcula acest scor valorile domeniului informational sunt din nou contorizate si ponderate Spre deosebire de calculul scorului functional, scorul caracteristic ia în considerare încã un domeniu de informatie (algoritmi) iar valorile de ponderare sunt fixe (vezi caseta "Calculul Scorului Caracteristic") Valoarea scorului caracteristic final se obtine din ecuatia: SC = totalul-de-calcul * 0 65 + 0 01 * SUM (Fi); De remarcat cã scorul caracteristic ia în considerare o nouã dimensiune a soft-ului, si anume algoritmii Inversarea unei matrici, decodificarea unui sir de biti sau tratarea unei întreruperi sunt toate exemple de algoritmi Trebuie de asemenea remarcat cã scorul caracteristic si cel functional semnificã acelasi lucru, si anume "functionalitatea" sau "utilitatea" furnizate de cãtre software În fapt, amândouã evaluãrile au drept rezultat aceeasi valoare a SF-ului în situatia calculului ingineresc conventional sau a aplicatiilor de tip gestiune a informatiilor Pentru sistemele în timp real, mult mai complexe, scorul caracteristic este adesea cu 20-35% mai mare decât cel calculat prin utilizarea în exclusivitate a scorului functional Utilizarea scorului functional - sau a celui caracteristic - este controversatã Partizanii ideii sustin cã SF (SC) este independent de limbajele de programare, aceasta fãcându-l ideal pentru aplicatii scrise în limbaje conventionale si neprocedurale Ei sustin de asemenea cã el este bazat pe date ce se presupun a fi cunoscute mult anterior în evolutia proiectului, fãcând SF (SC) mult mai atractiv ca estimare Pe de altã parte, oponentii ideii declarã cã metoda necesitã putinã prestidigitatie si cã realizarea calculului se face în parte pe baza unor date mai degrabã subiective decât obiective; ei mai cred cã informatiile pot fi dificil de strâns "dupã ce evenimentele au avut loc" si cã SF (SC) nu are o semnificatie fizicã directã - el este doar un simplu numãr AUTORI Iliuta Virgil: Introducere Metrici software(definitii, functii, caracteristici) Balint George: Metrici de complexitate(tipuri, Halstead, Mccabe) BIBLIOGRAFIE http://www software-metrics ase ro/articole/METRICI%20%20SOFTWARE htm http://cristi selfip com/wordpress/tag/metrici-software/ http://www scribd com/doc/56586879/Metrici-Software Zuse, H , Bollmann, P - Software metrics : using measurement theory the describe the properties and scales of static complexity metrics SIGPLAN Notices, vol 24, 1989 Whale, Geoff - Software Metrics and Plagiarism Detection Journal of Systems Software nr 13, 1990 IEEE Standard for a Software Quality Metrics Methodology IEEE Std 1061/1992 IEEE Standards Collection Software Engineering IEEE Press, New York, 1994 Scheneidewing, N F - Methodology for validating software metrics IEEE Transaction on Software Engineering, vol 18, nr 5, 1992 19 